Edge Mesh is a throwaway proof-of-concept / learning experiment built on top of the Greengrass reference implementation. It is not a supported or maintained deliverable and may be removed. The reference implementation itself is long-lived; Edge Mesh is not.
Alternatives & Portability
batman-adv is a well-contained implementation detail, not a load-bearing architectural choice. Everything above the mesh speaks plain TCP/IP to fixed 10.88.0.0/24 addresses, so the routing layer (and even the radio underneath it) can be swapped without touching the application components. The pieces that would need rework are the observability layer (the health portal's mesh map parses batctl output) and the provisioning tooling.
Read this if: you're evaluating whether this architecture survives replacing BATMAN, or moving to a different physical layer entirely.
Before this: read the Architecture page; this page leans on its three-layer model.
This page answers a design question rather than describing what's built: could we replace batman-adv, or change the underlying radio, and keep the rest? Short answer: yes. The three-layer model (radio → routing → IP) isn't just a description of the boot chain. The layers are independent, and this page walks the credible substitutions layer by layer.
The contract batman-adv actually fulfills
Everything the mesh carries (MQTT to Moquette at 10.88.0.1:8883, HTTP node-reports to :8080, the EdgeMesh relay, client-device cert provisioning) is ordinary unicast TCP/IP to well-known addresses. The only contract batman-adv fulfills for that traffic is:
Give every node an Ethernet-like interface (
bat0) on one L2 broadcast domain, and route frames between nodes multi-hop.
Anything that fulfills the same contract can be swapped in, and so can a routed-L3 equivalent, since the stack barely uses L2 semantics. The architecture's real load-bearing assumptions are:
- Every node has a stable IP and the core is reachable at a well-known address.
- There's enough bandwidth and low enough latency for TLS MQTT sessions and the interactive EdgeMesh relay.
- The mesh is an isolated side-channel, not an internet uplink (cellular stays the uplink on every node).
Alternative routing layers
L2 mesh (drop-in: fills the same bat0-shaped hole)
| Option | What it is | Trade-off vs. batman-adv |
|---|---|---|
| 802.11s / open80211s | Kernel-native Wi-Fi mesh with built-in HWMP routing | No out-of-tree module (kills the CompuLab cross-build problem). HWMP route selection is generally weaker than BATMAN's in lossy multi-hop networks. Driver support for mesh-point mode is as spotty as IBSS. |
| batman-adv (current) | L2 kernel routing over any carrier | Strongest pure-L2 option; the out-of-tree kernel module on the iMX8 is its main cost. |
The reference implementation is already halfway to 802.11s: the radio fallback unit
(mesh-wlan-mp.service.tmpl)
joins an 802.11s mesh when a radio can't do IBSS, but deliberately sets mesh_fwding 0 so batman-adv still does the routing. The cheapest possible experiment is flipping mesh_fwding back on, skipping batman-adv.service entirely (same subnet, same IPs, applications unaffected), and seeing whether HWMP routing is good enough on these radios.
Alternative physical layers
The rule of thumb: the architecture survives any PHY that delivers IP with headroom for TLS-MQTT plus the interactive relay. Below roughly Wi-Fi-class bandwidth you'd start redesigning the transport itself (CoAP/UDP, no per-node TLS sessions), and that would be a real architecture change.
| PHY | Range / bandwidth | Verdict for this architecture |
|---|---|---|
| 2.4 GHz Wi-Fi (current) | ~tens of meters/hop, Mbps | Works today. |
| 802.11ah (Wi-Fi HaLow) | Sub-GHz, ~1 km, still real IP bandwidth | The most interesting upgrade for jobsite-scale asset scanning. Routing layer rides on top unchanged. |
| 802.15.4 + Thread/OpenThread | ~100 m, tens of kbps, genuine IPv6 (6LoWPAN) | Fine for RP2 scan payloads; too thin and too high-latency for the EdgeMesh relay, the health portal, or the embedded terminal. |
| LoRa (Meshtastic etc.) | Kilometers, ~kbps | Not really IP; orders of magnitude too slow for MQTT-over-TLS. |
What actually is coupled to batman-adv
The data plane is mesh-agnostic. Two areas of the proof-of-concept software are not:
Observability. The health portal's mesh map is batman-specific:
health-portal/src/mesh.py
owns all batctl / originator-table parsing, and its link-quality semantics are BATMAN's TQ 0-255 metric (MESH_TQ_WARN = 100). The Pis' node reports
(pi/mesh_reporter.py)
carry batman MainIF MACs. A replacement routing layer needs a new topology backend (Babel exposes a local status socket; 802.11s has iw mpath dump), and each has a different link metric to map onto the warn/fail thresholds.
Provisioning & tooling. provision-pi.sh and the runbooks render batman-specific systemd units, and mesh-status.sh asserts batman health specifically.
Both are contained: they live in tools/mesh/, mesh.py, and mesh_reporter.py, not in the components that move actual data.